5 Prioritization Methods in UX Roadmapping UX 路線圖中的5種優先順序劃分方法

1. 影響-投入矩陣 (Impact–Effort Matrix)

1A. 概述

影響-投入矩陣是一種二維視覺化工具，將任務的使用者價值（影響）與實施複雜性（投入）進行對比，常用於Six Sigma、設計思維和敏捷開發等方法。矩陣分為四個象限：

快速獲益 (Quick Wins)：高影響、低投入，值得優先實施。

重大賭注 (Big Bets)：高影響、高投入，需謹慎規劃和驗證，但可能成為競爭優勢。

資源浪費 (Money Pits)：低影響、高投入，資源不值得投資。

填充項 (Fill-ins)：低影響、低投入，價值有限。

1B. 使用標準

影響 (Impact)：任務為使用者帶來的價值，包括解決痛點或提供新功能。

投入 (Effort)：實現任務所需的資源和工作量，複雜度越高，投入越大。

作為第一步，團隊成員對他們認為在其專業領域內排名最高的專案進行投票。例如，開發人員可能有黃點並對工作量進行排名，而設計師可能有橙點來代表對使用者的影響。

1C. 流程

列出候選任務。

讓團隊成員根據影響和投入對任務進行投票。

將任務根據投票結果繪製在矩陣上。

團隊討論和調整任務位置，優先處理“快速獲益”和“重大賭注”象限的任務。

1D. 最適用場景

適合快速協作優先順序劃分的場景。其優點包括：

共享的視覺化輸出，有助於建立共同理解。

方法簡單，團隊成員可快速表達意見。

適用於需要快速決策的專案環境。

2. 可行性、可取性和可行性評分卡

2A. 概述

此方法由IDEO開發，透過評分確定任務優先順序，評分標準包括可行性 (Feasibility)、可取性 (Desirability) 和可行性 (Viability)。

建立一個表格，在其中可以記錄專案的各個得分並將其相加得出總分。然後對總分進行比較、討論和重新組織，以確定最終的優先順序。總體得分最高的專案最能滿足優先順序標準（在這種情況下，為期望性、可行性和生存能力）。

2B. 使用標準

可行性 (Feasibility)：任務在技術上的可實現性。

可取性 (Desirability)：使用者的需求程度和任務的獨特價值。

可行性 (Viability)：任務的業務價值和長期可持續性。

2C. 流程

建立表格，列出任務和評分標準。

按1-10分制對任務進行評分（1為最低分）。

計算總分並對任務進行排序。

團隊討論排序結果並調整優先順序。

2D. 最適用場景

靈活性高，可根據需求調整標準。

適用於需要綜合考慮多因素的複雜專案。

3. RICE方法

3A. 概述

RICE方法由Intercom開發，基於影響範圍 (Reach)、影響力 (Impact)、信心 (Confidence) 和投入 (Effort) 確定優先順序。

RICE 方法透過將觸達（該專案影響的使用者數量）乘以影響（該專案對使用者產生的結果）和置信度（您對估計的驗證程度）來對專案進行排名。所得數字除以努力（實施該專案所需的工作量）以獲得專案的最終得分。

3B. 使用標準

Reach (影響範圍)：受影響使用者數量。

Impact (影響力)：任務對使用者體驗的提升程度。

Confidence (信心)：對評估準確性的信任程度。

Effort (投入)：完成任務所需的工作量。

3C. 流程

計算每個任務的評分：優先順序 = (Reach × Impact × Confidence) ÷ Effort

排序並討論結果。

3D. 最適用場景

適合技術導向型團隊。

適用於任務數量較多且需要詳細評估的場景。

4. MoSCoW分析

4A. 概述

MoSCoW分析將任務分為四類：必須有 (Must Have)、應該有 (Should Have)、可以有 (Could Have) 和不需要有 (Will Not Have)。

莫斯科分析將專案項分為四組：必須有（對專案至關重要的專案項）、應該有（非常重要但非必需的專案項）、可以有（可有可無的專案項）和不會有（不需要的專案項）。注：這裡的“MoSCoW”並非指莫斯科這個城市，而是一種需求優先順序排序的方法，所以在翻譯時按照其常見的翻譯方式進行了處理。如果您有特定的要求或上下文資訊，這個翻譯可能需要進行調整。

4B. 使用標準

Must Have：任務至關重要，缺少將導致專案失敗。

Should Have：任務支援核心功能，但非絕對必要。

Could Have：錦上添花的功能。

Will Not Have：價值較低的任務。

4C. 流程

列出任務，團隊成員進行加權投票（例如每人1、2、3分的票數）。

計算總分並將任務分配到對應類別。

根據資源優先處理“必須有”任務。

團隊成員對他們認為在路線圖時間範圍內是必須具備的專案進行投票。在上述示例中，每個團隊成員獲得三個投票點，一個標有 1，一個標有 2，一個標有 3。他們將自己的點放置在他們認為應具有最高優先順序的三個專案上（其中 3 表示在這三個專案中具有最高優先順序的專案）。

一旦團隊成員進行了投票，為每個專案計算一個分數，並將它們分為必須有、應該有、可以有和不會有。確保作為一個團隊進行討論，看所得出的層次結構對所有相關人員是否有意義。

4D. 最適用場景

適合明確時間範圍的專案，如敏捷開發團隊的短期規劃。

5. Kano模型

5A. 概述

Kano模型根據使用者滿意度和功能實現程度將任務分為四類：吸引型 (Attractive)、績效型 (Performance)、無差型 (Indifferent) 和必備型 (Must-be)。

卡諾模型根據滿意度和功能性對專案進行評分。使用這些評分，專案可以被分為 4 組：魅力型、績效型、無差異型和必備型。

5B. 使用標準

功能實現程度：從“無法實現”到“最佳實現” (-2 到 +2)。

使用者滿意度：從“非常不滿意”到“非常滿意” (-2 到 +2)。

5C. 流程

對任務進行滿意度和功能實現評分。

將任務繪製到二維圖上，分配到對應類別。

按優先順序排序：績效型 > 必備型 > 吸引型 > 無差型。

5D. 最適用場景

適合需要以使用者為中心討論任務優先順序的團隊，尤其是在政治或傳統開發文化較強的環境中。